Date: Sun,  1 Aug 93 04:30:02 PDT
From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu>
Errors-To: Packet-Radio-Errors@UCSD.Edu
Reply-To: Packet-Radio@UCSD.Edu
Precedence: Bulk
Subject: Packet-Radio Digest V93 #225
To: packet-radio


Packet-Radio Digest         Sun,  1 Aug 93       Volume 93 : Issue  225

Today's Topics:
                       Comments wanted for KPC3
                       CP/M software? (3 msgs)
                        DSP-2232 output level.
    Is  rec.radio.amateur.packet  about to die? Read on. (3 msgs)
                      Packet can't work (2 msgs)
                          Which TNC to Buy ?
                          X1J and the DR200

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 30 Jul 93 21:00:43 GMT
From: ogicse!hp-cv!hp-pcd!hpspkla!pace@network.ucsd.edu
Subject: Comments wanted for KPC3
To: packet-radio@ucsd.edu

Scott R. Ehrlich (sehrlich@lynx.dac.northeastern.edu) wrote:
: 
: A friend of mine is looking for an easy to use, cheap, TNC.
: Some friends of mine have the KPC3 and really like it.
: 
: I'd like to see what others on the net have so say about the unit.
: 
: Thanks much.
: 
: I will try to summarize the responses (if I get enough).
: 
: 73,
: Scott
: 
: ===============================================================================
: | Scott Ehrlich 	       Internet: acm_se@neu.edu                       |
: | Amateur Radio: wy1z          AX.25: wy1z@n0ary.#nocal.ca.usa.na             |
: ===============================================================================
: 
: -- 
: ===============================================================================
: | Scott Ehrlich 	       Internet: acm_se@neu.edu                       |
: | Amateur Radio: wy1z          AX.25: wy1z@n0ary.#nocal.ca.usa.na             |
: ===============================================================================
I have a friend who has a KPC3. He likes it and would buy another.

------------------------------

Date: 30 Jul 93 15:17:22 GMT
From: psinntp!gdc!horzepa@uunet.uu.net
Subject: CP/M software?
To: packet-radio@ucsd.edu

Anyone aware of any packet radio terminal emulation software for CP/M?
I had read about some recently (the last 2-3-4 months), but misplaced
the information. Any leads would be appreciated.

73,

Stan, WA1LOU
--
Stan Horzepa                   ~   phone:               203-758-1811 x7369
Technical Writing Supervisor   ~   email:               horzepa@gdc.com
General DataComm, Inc.         ~   radio:               WA1LOU
P. O. Box 1299                 ~   packet radio mail:   WA1LOU@N4GAA
Middlebury, CT 06762-1299      ~   TCP/IP packet radio: 44.88.0.14

~~~~~~~~~~~~~~~~~~~~~~~~~~~ What! - Me Worry? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

------------------------------

Date: Sat, 31 Jul 1993 00:03:14 GMT
From: news.cerf.net!crash!newshub.nosc.mil!dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!sdd.hp.com!col.hp.com!news.dtc.hp.com!srgenprp!alanb@network.ucsd.edu
Subject: CP/M software?
To: packet-radio@ucsd.edu

Stan Horzepa (horzepa@gdc.com) wrote:

: Anyone aware of any packet radio terminal emulation software for CP/M?
: I had read about some recently (the last 2-3-4 months), but misplaced
: the information. Any leads would be appreciated.

I don't know of any specifically for packet, but there's lots of general-
purpose terminal programs that should work fine for most TNCs.  Contact
the FOG users group (I can get the address if you don't have it) for
some freeware CP/M terminal programs.

AL N1AL

------------------------------

Date: 31 Jul 1993 02:09:26 GMT
From: usenet.coe.montana.edu!grapevine.lcs.mit.edu!ai-lab!regnad@decwrl.dec.com
Subject: CP/M software?
To: packet-radio@ucsd.edu

I use the CP/M terminal program ZMP for packet.  It works well enough, and
includes the YAPP protocol (in a seperate overlay).

Paul Prescott
N1AAC
regnad@gnu.ai.mit.edu

------------------------------

Date: 30 Jul 93 13:05:27 GMT
From: ogicse!uwm.edu!math.ohio-state.edu!darwin.sura.net!news.Vanderbilt.Edu!news@network.ucsd.edu
Subject: DSP-2232 output level.
To: packet-radio@ucsd.edu

I going to be using a DSP-2232 for digital satellite as well as HF
applications, and am finding that while it has a lot of very impressive
digital capabilities, that the analog parts are a little rough around the
edges.  Of particular concern is that the values used in the interchip
coupling components result in the output voltage being roughly
proportional to the baud rate.  So far I am using a small box with lots
of resistors, one for each radio and mode.  Does anyone have a clean fix
or mod?  AEA essentially says that this is "normal" and should cause no
problem since you just use the mike gain.  However, for most modes you need
to bypass the normal audio feeds.  There must be a way to do this right,
since the competing DSP-12 have constant output for all modes.

Alan


************************************************************************
Alan P. Biddle, Ph.D.        PACKET       WA4SCA @ W4HHY.TN.USA.NA
Computers of Arisia                       
1778 Pleasant Hill Road      INTERNET     WA4SCA@AMSAT.ORG               
Franklin, TN 37064                        BIDDLEAP@CTRVAX.VANDERBILT.EDU
(615) 776-2056                
(615) 330-2569                CIS          73260,1450   
************************************************************************

------------------------------

Date: 31 Jul 93 18:16:58 GMT
From: ogicse!emory!rsiatl!ke4zv!gary@network.ucsd.edu
Subject: Is  rec.radio.amateur.packet  about to die? Read on.
To: packet-radio@ucsd.edu

In article <23bfs4INNd1h@network.ucsd.edu> brian@nothing.ucsd.edu (Brian Kantor) writes:
>
>Well, you see, a bunch of newbies decided they had a better way to run
>things, and managed to dupe enough people into voting for a few of the
>massive numbers of groups they thought would help balkanize the
>discussions they didn't want to see any more, so there are a bunch of
>new groups.

Don't hold back, tell us how you *really* feel Brian. :-)

The issues were settled by a couple dozen votes out of a couple
hundred total votes. Most of the thousands of readers of the 
ham-radio groups didn't speak. But that's the way Usenet works.

Gary

-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: 31 Jul 93 02:33:23 GMT
From: pacbell.com!amdahl!amdahl!ikluft@ames.arpa
Subject: Is rec.radio.amateur.packet about to die? Read on.
To: packet-radio@ucsd.edu

brian@nothing.ucsd.edu (Brian Kantor) writes:
>Well, you see, a bunch of newbies decided they had a better way to run
>things, and managed to dupe enough people into voting for a few of the
>massive numbers of groups they thought would help balkanize the
>discussions they didn't want to see any more, so there are a bunch of
>new groups.

Brian, I'm shocked (almost.)  For someone with a good understanding of UseNet,
you are showing very little respect for some of the few established UseNet
processes (i.e. voting.)  OK, so some of it didn't go the way you wanted -
but it was voted on and the votes passed by the required 2-to-1 margins and
100 more yes's than no's.

Now you're saying those people who voted yes were duped into it?  That would
have required someone to be campaigning for it.  When the voting started, I
didn't see anyone doing that, and I was encouraging people to vote by their
opinion whether it was yes or no.  (My reason was that it would be worse to
campaign and risk a backlash from people who didn't like it.)

So you might want to consider the possibility that a 2-to-1 majority really
did choose those newsgroups that passed.  And I mean each person on their
own chose it.

>[...]  Thus the result of the vote was that all that's being
>accomplished is to change the name of a successful group to one that's
>a bit less obvious, and which - to this point at least - has not been
>very well received by the Usenet ham populace.

Any why might that be??  Hmmm...  Perhaps because someone is still gating
a mailing list into the soon-to-be-rmgroup'ed newsgroup.  That's almost
certainly maintaining some level of traffic here when it should be dwindling
to nothing during the transition to rec.radio.amateur.digital.misc.  As
long as there's discussion in rec.radio.amateur.packet, many people won't
move to the new group.

On the bright side, I saw that you've posted a question about what people
want with the mail lists.  That's good - please expedite some sort of action
on the matter.  It appears like the available options are
* moving the mail list to rec.radio.amateur.digital.misc (with somewhat of
  a mismatch in scope between the digital and packet topics),
* detaching the mailing list from the newsgroup entirely,
* shutting down the mailing list, or
* changing the name of the mail list to match the new newsgroup. (My guess is
  this one is not likely to happen.)

It's your choice since you're the mail list gateway administrator.  But choose
something soon.
-- 
Ian Kluft  KD6EUI PP-ASEL         Amdahl Corporation, Open Systems Development
ikluft@uts.amdahl.com                                          Santa Clara, CA
[disclaimer: any opinions expressed are mine only... not those of my employer]

------------------------------

Date: Fri, 30 Jul 1993 16:56:24 GMT
From: pravda.sdsc.edu!news.cerf.net!usc!math.ohio-state.edu!sol.ctr.columbia.edu!news.unomaha.edu!cwis!pschleck@network.ucsd.edu
Subject: Is rec.radio.amateur.packet about to die? Read on.
To: packet-radio@ucsd.edu

In <23bfs4INNd1h@network.ucsd.edu> brian@nothing.ucsd.edu (Brian Kantor) writes:

>da884@cleveland.Freenet.Edu (David Toste) writes:
>>
>>NOTE: rec.radio.amateur.packet        0921  rec.radio.amateur.digital.misc
>>
>>Looks to me that the last day for this group is on Sept 21th~!!!
>>
>>What gives?

>Well, you see, a bunch of newbies decided they had a better way to run
                           ^^^^^^^

If being on the net for almost 3 years, and making substantial
contributions to the FAQ's and other information resources makes one a
"newbie," then I and everyone else on rra-reorg (now rra-wg) is guilty
(Hear that Jay?  You're a "newbie!" :-).  We've also made it clear that
we recognize your experience, and seek your opinions whenever possible
(although we may not always agree). 

One of the risks of a heterogeneous, distributed environment like
Netnews is that others are going arrive on-scene and possibly take the
newsgroups in directions other than what the originators wanted.  In a
voluntary environment, you've gotta lead, follow, or get out of the way.
If a group of motivated people, with the support of a majority of the
readers, want to move in a specific direction, I see no cause for
complaint.  Don't forget that every new newsgroup passed with a 2/3
majority of the readership and at least a 100-vote margin between yes
and no. 
 
>things, and managed to dupe enough people into voting for a few of the
>massive numbers of groups they thought would help balkanize the
>discussions they didn't want to see any more, so there are a bunch of
>new groups.

>Some of these new groups are working out well - the antennas and
>homebrew groups have proven to be popular.  Others are nearly idle.

I think there's a complement in there somewhere.  Actually, all of the
newsgroups are successful.  If you are referring to the *.space group,
that at least serves as a target for the satellite elements, space
bulletins, and "Space News" that crowded Info-Hams.

>One of the ideas was that rec.radio.amateur.packet (formerly known as
>rec.ham-radio.packet) was to be superseded by a two or more new groups,
>of which rec.radio.amateur.digital.misc was one.  However, the votes
>weren't there for the other ...digital group(s), and they didn't get
>created.  Thus the result of the vote was that all that's being
>accomplished is to change the name of a successful group to one that's
>a bit less obvious, and which - to this point at least - has not been
>very well received by the Usenet ham populace.

>It would have been wisest, perhaps, to make the replacement of
>rec.radio.amateur.packet with a new group/name contingent on more than
>one of the new digital subgroups passing, otherwise to leave things
>well enough alone.  That wasn't what was done.

There is no way such "conditional" referenda can be performed within
the present Usenet voting guidelines.  We had to consider all of the RFD
input, and go with a set of groups that had the greatest support, and
least damage if only some of them passed. 

Such are the pitfalls of a collaborative, democratic process where the
results are not known in advance.  It was undesirable from a number of
technical perspectives to have a "split" hierarchy under
rec.radio.amateur.[digital,packet], hence the desire to add a *.misc
group.  I'll admit it was truly a surprise that there would be support
(or at least lack of objection) to splitting packet into
digital.misc/digital.tcp-ip in the RFD, only to have a significant number 
of people vote for one and not the other (about 20-30, I believe).
We guessed somewhat wrong, but I don't see how anyone could have guessed
any better, based on the available information.

Of course, since newsgroup votes can be revisited in 6 months, you'd
better believe that rec.radio.amateur.digital.tcp-ip is going to
reapproached.  Not to supersede TCP-GROUP (as that clearly is a
desirable semi-private developer's and expert-user's mailing list,
thanks for pointing that out in the RFD), but to create a user-level
Usenet newsgroup for a significant subset of packet experimentation,
independent of any pre-existing mailing lists.

I *HOPE* I'm not reading your objections to digital.misc as an
implication that you're not going to gateway PACKET-RADIO to it at the
appropriate time.  That would be a extremely immature, bitter, and
obstructionist thing to do (which is why I'm pretty certain I'm
mistaken). 

We've been pretty successful recently (for the past year at least), in
agreeing-to-disagree on certain issues, and not turning the ham-radio
groups into another meta-discussion battlefield over parochical,
minority-interest issues.  I hope that this isn't going to get ugly
again. 

Come on Brian, let's work together, and not at potentially
cross-purposes.

73, Paul W. Schleck, KD3FU

pschleck@unomaha.edu

------------------------------

Date: 31 Jul 93 18:25:26 GMT
From: ogicse!emory!rsiatl!ke4zv!gary@network.ucsd.edu
Subject: Packet can't work
To: packet-radio@ucsd.edu

In article <25257@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes:
>In article <1865@arrl.org> jbloom@arrl.org (Jon Bloom, KE3Z) writes:
>>>
>>>to duplex repeaters instead of digipeaters to solve it. The hidden
>>>terminal problem goes away because now you hear everything the
>>>repeater hears in real time. And, if you operate your station in
>>>full duplex as well, you can even implement CD.
>>
>>Has anyone actually implemented CD that way?  I'd love to get in
>>touch with anyone who has and who would be willing to write it up
>>for QEX or the Digital Conference Proceedings.
>
>How would you implement it ? If you get a collision, the output of
>the repeater will be one of :
>
> Unchanged, due to FM capture effect. 
>
> The losing node should still stop transmitting, as it worsens the noise 
> at the repeater  - but to do so, it's got to monitor the repeater output 
> to determine who won. This is particularly awkward if you've got a high 
> speed system that uses DMA, since the processor doesn't know what the 
> data is until it's all received. 
> It's possible SDLC hardware addresses could be used, though.
>
> Completely screwed up, since both signals are received.
>
> This would probably be less common unless the transmitter power settings
> were carefully managed, but would appear as an active carrier together
> with an unrecoverable data clock at the repeater's input. That might
> be hard to distinguish from a too-distant user, but I'm not sure.
>
>Either way, it doesn't seem to scale too well to a faster system, where
>the round trip time is comparable with the packet length. In this case,
>you only find out about the collision after it happened ..

You've identified the core problem, round trip time. Conceptually,
it's simple to implement CD. You just keep a FIFO of the last few
bits you transmitted and match them against the bits being received
from the repeater. If they're the same, keep transmitting, if they're
different, stop. The problem, as you've noted, is that stations at
different distances from the repeater have different round trip 
times. This requires a synchronizing adjustment be made. In the
pathological case, the synchronizing delay is longer than the
packet.

Gary

-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: 30 Jul 93 17:10:43 GMT
From: pipex!uknet!acorn!agodwin@uunet.uu.net
Subject: Packet can't work
To: packet-radio@ucsd.edu

In article <1865@arrl.org> jbloom@arrl.org (Jon Bloom, KE3Z) writes:
>>
>>to duplex repeaters instead of digipeaters to solve it. The hidden
>>terminal problem goes away because now you hear everything the
>>repeater hears in real time. And, if you operate your station in
>>full duplex as well, you can even implement CD.
>
>Has anyone actually implemented CD that way?  I'd love to get in
>touch with anyone who has and who would be willing to write it up
>for QEX or the Digital Conference Proceedings.

How would you implement it ? If you get a collision, the output of
the repeater will be one of :

 Unchanged, due to FM capture effect. 

 The losing node should still stop transmitting, as it worsens the noise 
 at the repeater  - but to do so, it's got to monitor the repeater output 
 to determine who won. This is particularly awkward if you've got a high 
 speed system that uses DMA, since the processor doesn't know what the 
 data is until it's all received. 
 It's possible SDLC hardware addresses could be used, though.

 Completely screwed up, since both signals are received.

 This would probably be less common unless the transmitter power settings
 were carefully managed, but would appear as an active carrier together
 with an unrecoverable data clock at the repeater's input. That might
 be hard to distinguish from a too-distant user, but I'm not sure.

Either way, it doesn't seem to scale too well to a faster system, where
the round trip time is comparable with the packet length. In this case,
you only find out about the collision after it happened ..

-adrian


 

------------------------------

Date: 29 Jul 93 14:17:44 EDT
From: pacbell.com!iggy.GW.Vitalink.COM!wetware!spunky.RedBrick.COM!psinntp!psinntp!pbs.org!pbs!jernandez@network.ucsd.edu
Subject: Which TNC to Buy ?
To: packet-radio@ucsd.edu

	I am new to the packet game in amateur radio. I understand how it works because I am
	because I am in the communication business. What I need to know is which
	TNC people recommend. Which is better: the PK-232 or the MFj-1278. I am
	interested in a unit that will do packet as well as other modes.

	Thanks
	John
	KA2YAP

------------------------------

Date: Fri, 30 Jul 1993 04:57:28 GMT
From: usenet.coe.montana.edu!netnews.nwnet.net!raven.alaska.edu!aurora.alaska.edu!ifjrs@decwrl.dec.com
Subject: X1J and the DR200
To: packet-radio@ucsd.edu

In article <22s7qt$alj@gopher.cs.uofs.edu>, bill@gopher.cs.uofs.edu (Bill Gunshannon) writes:
> 
> Has anyone with access to the source looked at putting a version
> of X1? on the DR200??  It seems that the dual port box would
> make a great IP gateway between a local LAN and a backbone.
> 
> bill   KB3YV
> 
> --
> 
> Bill Gunshannon          | "There are no evil thoughts, Mr. Rearden" Francisco
> bill@cs.uofs.edu         |  said softly, "except one; the refusal to think."
> University of Scranton   |
> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
-- 
Bill, I've been pushing this for almost a year!  I sent a packet last Dec. (?)
to the author, and got an acknowledgement that he received my msg, but that
he hadn't yet had a chance to read it.  Hadn't heard anything since, so I
sent another one just a few days ago re the possible porting of X1? to the
DR-200.  So far, no response, but let's give it a few days!

Also, if others like this idea, let's get a little vocal here, as this is
the first mention I've seen of the DR-200 in ages.

I don't get on here all that often, so it might be a good idea (even though
it's not exactly tcp/ip related) to the tcp-group?

73, John
--

John Stannard
ifjrs@acad3.alaska.edu		BITNET:  IFJRS@ALASKA
KL7JL@KL7JL.AK.USA.NA		kl7jl.ampr.org  [44.22.0.1]

"God is the Answer!"   "Oh?? ... er, ... What was the Question?"

--

------------------------------

Date: 30 Jul 93 16:58:52 GMT
From: pipex!uknet!acorn!agodwin@uunet.uu.net
To: packet-radio@ucsd.edu

References <1993Jul28.034200.9730@cs.yale.edu>, <25223@acorn.co.uk>, <1993Jul29.180807.13354@ke4zv.uucp>du
Subject : Re: Packet can't work

In article <1993Jul29.180807.13354@ke4zv.uucp> gary@ke4zv.UUCP (Gary Coffman) writes:
>
>Channel pathology can still be a problem if stations aren't using
>p-persistance backoff. Stations can still butt heads again and 
>again if they use a fixed Dwait and both happen to start during the
>window of vulnerability. And they *will* always start during the
>window if the channel is busy. Both will try to transmit as soon
>as data carrier from a previous channel user drops. So p-persistance
>is essential to making a busy channel work, whether it's duplex or
>simplex.
>

Right, but p-persistence only helps by deliberately introducing some
dead-time, just as polling systems introduce their own overhead.

In both cases, the inefficiency introduced is related to the number
of users on the channel (since the p-persist coefficient is supposed
to be related to the expected load) but it's possibly more convenient
to have the central hub adjust the loading than the user's nodes.
Of course, this doesn't preclude the user's nodes being adjusted by
some other, centralised authority based at the repeater.

-adrian

------------------------------

Date: Thu, 29 Jul 1993 18:37:14 GMT
From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu!jvp@network.ucsd.edu
To: packet-radio@ucsd.edu

References <1993Jul23.230640.10707@emba.uvm.edu>, <fArVsAJABh107h@pauln.uucp>, <tom_taylor-280793174257@kip-27.taligent.com>
Subject : Re: N0ARY

In <tom_taylor-280793174257@kip-27.taligent.com> tom_taylor@taligent.com (Tom Taylor) writes:

>Not only that, but the custom software he wrote runs on his own network of
>Sun machines.  At least it did six months ago when he came and gave a
>talk at the Apple ham radio club.

Not only that, but Bob's BBS software is the best I have _ever_ seen.

--
+-----------------------------------------------------------------+
| Jim Van Peursem - Dept of EE and CprE - Iowa State University   |
| Ames, IA 50011 - internet: jvp@iastate or tools1.ee.iastate.edu |
+-----------------------------------------------------------------+

------------------------------

End of Packet-Radio Digest V93 #225
******************************
